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1.  Identification  and  Significance  of  the  Problem  or  Opportunity 

In  the  areas  of  chemical  and  biological  defense,  sensors  play  a  critical  role  in  providing  data  for 
the  information  fusion  and  decision  support  systems  and  their  users.  The  input  to  decision 
support  systems  is  the  result  of  all  the  processes  that  occur  from  the  source  of  the  threat  to  the 
output  of  the  sensors  and  associated  detection  systems.  The  output  of  sensors  is  determined  by 
the  chained  sequence  of  processes,  beginning  at  the  threat  source  and  propagating  through  the 
channel  between  the  source  and  the  sensor  input.  The  detection  system  itself  only  imperfectly 
reproduces  or  classifies  this  distorted  signal.  The  sensor  fusion  or  decision  support  systems  must 
interpret  this  imperfect  data  in  a  manner  that  provides  accurate  information  to  decision-makers. 
This  research  project  developed  tools  to  assist  in  modeling  and  understanding  the  behavior  of 
chemical  detection  systems. 
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Figure  1.  Information  Flow  from  Source  Cloud  to  Decision  Support  System 

Figure  1  shows  the  flow  of  information  from  a  chemical  agent  or  simulation  of  an  agent  through 
other  intermediate  processes  into  a  detection  instrument.  The  input  to  the  chemical/biological 
detection  instruments  must  include  the  following  sequence  of  processes  or  process  simulations: 

•  agent  source  and  initial  agent  distribution, 

•  agent  transport  and  dispersion  through  the  atmosphere, 

•  concentration  fluctuations  due  to  characteristic  turbulence  in  the  atmospheric  mixing 
layer,  planetary  boundary  layer,  and  near  the  inlet  of  a  point  detector, 

•  distortions  caused  by  transport  of  matter  or  radiation  to  the  transducer  sensor  component 
that  converts  either  the  radiation  or  chemical  inlet  to  an  electrical  output, 

•  the  method  of  signal  transduction  and  associated  electronic  signal  conditioning, 

•  the  effects  of  interfered  chemical  species  as  well  as  interfering  ambient  and  jamming 
radiation  on  sensor  signal  transduction, 

•  data  reduction  algorithms  for  both  signal  and  intrinsic  noise,  and 

•  the  algorithms  that  translate  the  digitized  electrical  signals  or  spectra  into  information  on 
agent  concentration,  type  and  distribution. 
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The  outputs  from  this  sequence  form  the  inputs  to  detection  instrument  data  fusion  and  C4I 
decision  support  systems.  The  output  of  the  detector/sensor  is  not  the  information  being  sought 
by  commander  decision  support  systems;  rather,  these  decision  support  systems  require  accurate 
reproduction  of  the  sensor  inputs  and  environmental  conditions. 

1. 1.  Survey  of  Chemical  Detection  Systems 


Figure  2.  Sensors  and  Decision  Support  in  Battlefield  C4I  using  a  Chem./Bio  Scenario  (US . 
Department  of  Defense,  1997) 

Figure  2  shows  common  sources  of  sensor  data  in  a  chem./bio  defense  scenario.  Decision 
support  systems  for  Chemical  and  Biological  Defense  (CBD)  rely  heavily  on  both  raw  and 
transformed  sensor  data.  Chemical  and  biological  detection  systems  incorporate  a  variety  of 
physical  sensors.  A  chem/bio  sensor  is  a  transducer,  which  represents  the  concentration  of  toxic 
agents  by  transforming  a  physically  measured  property  to  an  electrical  output. 

Point  detectors  transform  in  situ  chemical  concentrations  to  an  output  current  or  voltage.  Point 
detectors  take  samples  of  the  atmosphere  that  interacts  with  the  sensor,  sometimes  after  a 
separation  technique.  Many  interaction  mechanisms  are  possible,  but  all  of  them  result  in  either 
charge  generation  or  changes  in  electrical  potential.  Examples  include  ion  mobility 
spectrometry,  surface  acoustic  wave  techniques,  flame  photometry,  catalyst  coated  solid  polymer 
electrolyte  devices,  and  various  surfaces  or  solutions  coated  with  bioactive  organisms  or 
compounds. 

Standoff  detectors  transform  the  complex  emission,  absorption,  reflection  and  propagation  of 
electromagnetic  signals  through  the  atmosphere  into  an  electrical  output  pattern.  The  two  main 
types  of  standoff  detectors  are  passive  and  active.  Passive  standoff  detectors  measure  the 
radiation  incident  on  a  detector  from  the  atmosphere  using  ambient  light  to  serve  as  the  light 
source.  In  these  systems,  the  detectors  capture  the  composite  spectra  of  many  atmospheric 
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gases.  Both  active  and  passive  detection  involves  separating  the  spectra  of  benign  and 
background  gases  from  potentially  toxic  components  of  the  atmosphere. 

Active  standoff  detection  systems  generate  an  electromagnetic  wave  at  the  source  (e.g.,  laser, 
Xe-arc  lamp)  and  then  detect  the  returned  wave  using  an  optical  receiver  (e.g.,  optics,  beam 
splitting  lenses  and  mirrors,  optical  detectors).  The  delayed,  attenuated  and  phase-shifted  return 
signal  is  matched  against  the  expected  return  signal  in  the  presence  or  absence  of  a  toxic  agent. 

A  high  fidelity  atmospheric  model  is  needed  to  provide  baseline  wave  propagation  predictions 
and  enable  the  subsequent  creation  of  pattern  recognition  algorithms  to  identify  the  constituent 
chemicals.  A  prominent  form  of  active  standoff  detector  is  an  infrared  optical  radar,  commonly 
known  as  Light  Detection  and  Ranging  (LIDAR).  Chemical  identification  of  toxic  agents  in 
clouds  is  enhanced  by  using  dual  wavelength,  dual  beam  sources  in  a  form  of  LIDAR  known  as 
Differential  Absorption  LIDAR  (DIAL). 

Each  type  of  sensor  has  different  input/output  characteristics  and  operates  through  different 
physical  mechanisms.  The  impact  and  effects  of  environmental  processes  on  the  detection 
system  will  depend  on  the  specific  mechanisms  of  each  detection  process.  However,  all  detection 
systems  will  be  influenced  by  common  atmospheric  properties  and  processes,  including  the 
presence  of  interferents,  thermodynamics  and  physical  properties,  agent  transport  and  dispersion, 
and  environmental  turbulence  characteristics.  Many  of  the  inputs  to  the  detection  systems  result 
from  stochastic  processes,  and  observations  contain  uncertainty  at  various  levels  of  the  detection 
process.  In  many  cases,  detection  systems  will  need  to  fuse  data  from  multiple  types  of  sensors 
and  associated  interpretation  algorithms  to  provide  more  robust  identification  and  quantification 
of  toxic  agents  in  the  environment. 

In  principal,  the  point,  active  standoff,  and  passive  standoff  detection  techniques  can  effectively 
detect  chemical/biological  agents.  In  practice,  the  detectors  do  not  exhibit  ideal  behavior  and 
their  inputs  in  the  natural  environment  (e.g.,  stochastic  processes)  deviate  substantially  from 
those  used  in  typical  laboratory  tests.  Point  detectors  are  typically  used  for  alerting  and  alarming 
personnel  in  the  immediate  area  to  the  existence  of  toxic  compounds.  The  observation  point  may 
or  may  not  be  representative  of  the  immediate  surrounding  area  or  the  larger  battle  area.  For  this 
reason,  point  detectors  are  deployed  in  arrays  or  mobile  platforms.  Because  standoff  detectors 
provide  spatially  averaged  data  concerning  the  existence  and  concentration  of  agents,  they  are 
most  commonly  used  for  identifying  threat  clouds  and  alerting  field  personnel  to  an  incipient 
threat. 


1.2.  Significance  of  Accurate  Modeling  of  Chemical  and  Biological 
Detection  Systems 

There  are  challenges  and  deficiencies  in  current  detection  technologies  and  their  deployment, 
such  as  high  false  alarm  rates,  sensitivity  to  interferents,  suboptimal  data  interpretation 
algorithms,  and  inability  to  adapt  to  new  threats.  The  effectiveness  of  chem/bio  detection, 
information  fusion,  and  decision  support  systems  depends  greatly  on  their  ability  to  incorporate 
sophisticated  and  accurate  information,  such  as  expected  detector  performance  under  various 
conditions,  ranges  of  realistic  operational  conditions/limitations,  and  meaningful  representations 
of  uncertainties  and  effects  arising  from  environmental  conditions.  DoD  and  DHS  platforms  in 
the  areas  of  hazard  prediction/assessment  (e.g.,  JEM,  DTRA  HP  AC,  JWARN),  detector 
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design/deployment,  and  consequence  management  would  benefit  from  an  integrated  solution  that 
accurately  simulates  sensors,  detection  systems,  and  arrays  of  detection  systems  under  realistic 
conditions. 

Accurate  modeling  and  simulating  the  behavior  of  detection  systems  under  real-world  conditions 
can  aid  the  design,  development,  and  test  of  detection  systems  themselves  and  other  systems  that 
operate  upon  their  data.  Other  existing  CB  sensor  modeling,  simulation  and  acquisition 
environments  do  not  accurately  predict  CB  detector  performance  under  realistic  battlespace 
conditions.  For  example,  some  DoD  training  systems  utilize  a  lookup  table  of  prerecorded  field 
data  observations  of  the  detection  systems.  Field  test  data,  including  data  collected  at  U.S.  Army 
Dugway  Proving  Ground,  is  critical  for  the  verification  and  validation  of  sensor  models  and 
simulations.  While  real  field  data  on  sensor  performance  can  be  collected  at  test  ranges,  the 
results  do  not  necessarily  predict  the  performance  of  that  instrument  in  different  locations  and 
operating  conditions  (e.g.,  Winter  in  Afghanistan  or  Summer  in  Iraq).  The  predictive  power  of 
real  field  data  is  limited  because  they  can  only  span  a  very  limited  portion  of  the  mission  space 
of  the  detector.  Therefore,  while  field  data  may  be  useful  for  some  training  systems,  this 
approach  can  not  meet  the  requirement  to  predict  future  behaviors. 

The  chem/bio  simulations  should  incorporate  a  combination  of  chemical/physical  and  empirical 
models,  their  associated  uncertainties,  and  realistic  conditions.  These  accurate  models  and 
simulations  of  decision  support  input  data  from  sensors  and  other  sources  enable  effective 
development,  test,  and  evaluation  and  use  of  decision  support  systems.  In  order  to  predict  an 
output  of  a  sensor  system  under  any  arbitrary  conditions  within  its  mission  space,  a  complete 
dynamic  (time  varying)  model  is  required.  Empirical  models  determine  their  parameters  from 
data  (e.g.,  scene  generator  data,  experimental  detector  data,  simulation  data  from  atmospheric 
models)  and  performance  measures  that  characterize  a  system  over  its  entire  mission  space. 
Therefore,  dynamic  models  and  simulations  valid  over  the  entire  mission  space  are  needed  to 
provide  sensor  output  data  that  facilitates  the  design  of  decision  support  systems  effective  over  a 
full  range  of  battlefield  situations. 

1.3.  Need  for  a  Comprehensive  Detection  Systems  Simulation  Architecture 
and  Framework 

The  utilization  of  high  fidelity,  dynamic  chemical  detection  models  can  increase  the  efficiency 
and  reduce  the  time  to  design,  develop,  test,  and  refine  chemical  detection  systems  and 
information  fusion  systems.  A  single  monolithic  model  capturing  all  of  the  behaviors  of  a  given 
sensor  or  sensor  suite  would  be  inflexible,  difficult  to  maintain,  and  computationally  inefficient. 
Likewise,  a  collection  of  high  quality  models  of  different  aspects  of  the  detection  process  would 
be  most  useful  if  the  results  of  one  simulation  is  available  as  the  input  to  another,  in  real-time. 
For  the  user  community  to  realize  the  potential  of  simulation-based  acquisition,  design,  and  test, 
the  users  need  a  software  architecture  that  enables  them  to  integrate  models  from  various 
sources,  modify  these  models,  validate  them,  and  use  them  for  the  purposes  of  design,  test,  and 
analysis. 

An  environment  which  permits  the  flexible  authoring  and  assembly  of  sensor/detection  system 
components,  along  with  their  associated  uncertainties,  would  enable  the  stakeholders  to 
effectively  reuse  simulation  resources  and  rapidly  test  a  variety  of  scenarios  and  optimization 
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criteria.  Composability  is  “the  capacity  to  select  and  assemble  simulation  components  in  various 
combinations  into  simulation  systems  for  different  purposes”  (Petty  and  Weisel,  2003).  The 
benefits  of  composability  include  more  comprehensive  simulations,  the  ability  to  enforce 
consistent  assumptions,  increased  validity,  and  more  efficient  and  responsive  use  of  resources 
(Kasputis  and  Ng,  2000).  In  a  sensor  simulation  environment,  composability  would  facilitate  the 
creation,  maintenance,  and  reuse  of  libraries  of  sensor/detection  simulation  components 
optimized  for  various  fidelities,  scenarios,  and  assumptions.  Simulation  software  developers, 
modelers,  integrators,  testers,  and  users  require  the  ability  to  rapidly  and  flexibly  develop  and 
compose  new  components  and  simulations  to  satisfy  the  specific  needs  of  the  user.  This  will 
require  the  rapid  configuration,  verification,  validation  and  deployment  of  these  components. 

There  are  several  initiatives  in  the  simulation  community  for  the  creation  of  composable 
simulation  environments,  including  the  extensible  Modeling  and  Simulation  Framework 
(XMSF)  initiative  (Brutzman,  2003),  the  SISO  Base  Object  Model  (BOM)  Product  Development 
Group  effort  (Simventions,  2005),  and  the  Simulation  Reference  Markup  Language  (SRML).  In 
the  efforts  by  the  SISO  BOM  PDG,  a  BOM  represents  information  (e.g.,  metadata)  about  a 
single  simulation  federate,  represented  in  XML.  The  SISO  BOM  PDG  is  developing  standards 
for  BOMs  that  will  enable  simulation  interoperability,  reusability,  and  composability.  The 
extensible  Modeling  and  Simulation  Framework  (XMSF)  is  an  initiative  to  define  a  set  of  web- 
based  technologies  to  support  interoperability  among  Modeling  &  Simulation  (M&S) 
applications  (Brutzman,  2003).  The  Simulation  Reference  Markup  Language  (SRML), 
submitted  by  Boeing  to  W3C,  describes  some  basic  metadata  for  simulation  BOMs  in  XML,  as 
well  as  additional  functionality  for  representing  behavior  (e.g.,  scripting  capabilities) 
(Reichenthal,  2003;  Boeing,  2003).  These  efforts  complement  the  research  described  in  this 
report. 

1.4.  Software  Implementations  of  a  Sensor  Simulation  Environment 

At  present,  an  integrated  solution,  including  source  code  Integrated  Development  Environment 
(IDE),  visual  composition  environment,  source  code  and  version  management,  management  of 
various  simulation  resources,  and  domain-specific  libraries,  does  not  exist  for  chem/bio  detection 
simulations.  However,  several  Department  of  Defense  contractors  have  developed  systems  that 
have  a  predefined  library  of  chem/bio  sensor  models  and  interfaces  to  DoD  standards.  These 
systems  readily  integrate  with  existing  DoD  simulation  standards  and  have  been  successfully 
deployed  for  some  applications  (e.g.,  training,  battlefield  scenario  assessment). 

Many  of  these  chem/bio  detection  simulation  environments  incorporate  simplistic  or  inaccurate 
chem/bio  detection  systems  models,  leading  to  suboptimal  allocation  of  resources  and  reduced 
probability  of  mission  success.  For  example,  many  of  these  simulation  environments  do  not 
incorporate  realistic  physico-chemical  models,  are  not  typically  capable  of  predicting  real-world 
outputs  under  the  time  varying  or  turbulent  conditions  expected  in  the  battlespace  or  homeland, 
and  do  not  incorporate  relevant  forms  of  uncertainty  (e.g.,  stochastic  processes,  numerical 
precision,  etc.). 

In  addition  to  the  more  proprietary  chem/bio  simulation  offerings,  there  are  also  general-purpose 
commercial-off-the-shelf  (COTS)  environments  for  simulation  and  simulation  development. 
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Among  the  most  widely  used  and  respected  is  Mathworks  Simulink®  which  provides  a  toolset 
for  modeling,  simulating,  and  analyzing  dynamic  multi-domain  systems. 

1.5.  Benefits 

Many  existing  CBD  decision  support  systems  will  benefit  from  the  incorporation  of  more 
accurate  understanding  and  description  of  the  outputs  of  the  sensor  components  of  detection 
systems.  At  present,  DTRA  HP  AC  and  JEM  have  high  quality  decision  support,  casualty 
prediction,  and  atmospheric  modeling  capabilities  to  support  chemical/biological  defense. 
Simulation  developers,  detection  systems  designers,  decision  support  system  developers,  and 
other  decision  makers  within  various  DoD  test  and  evaluation  facilities  need  a  comprehensive 
tool  that  integrates  atmospheric  models,  chem/bio  detector  models,  and  information 
fusion/decision  support  systems.  For  example,  decision  support  systems  such  JWARN  and  Army 
Future  Combat  Systems  would  benefit  from  working  with  realistic  representations  of  detector 
responses. 

Modeling  the  behavior  of  the  sensor  or  detection  systems  would  also  enable  the  development, 
test,  evaluation,  and  effective  utilization  of  sensor  interpretation  and  fusion  algorithms  that 
address  these  issues.  These  models  would  also  enable  the  optimization  of  system  performance  by 
alteration  in  detection  hardware  and  software  system  architecture,  components,  and  parameters. 

The  prototype  developed  in  this  research  enables  the  development,  integration,  execution,  and 
analysis  of  models  that  accurately  predict  sensor  performance.  While  this  may  expose 
previously  unanticipated  limitations,  it  will  also  provide  defensible  and  believable  predictions  of 
operational  performance  for  the  ultimate  users,  the  military  in  the  field.  In  this  research,  the 
investigators  focused  on  demonstrations  of  models  of  chemical  and  biological  (CB)  detectors  as 
the  problem  of  CB  detection  represents  a  still  unsolved  challenge  for  homeland  and  military 
defense  and  response.  However,  the  technologies  could  be  applied  to  other  sensor  modeling 
domains  in  the  future. 

2.  Technical  Objectives  for  the  Phase  II  Research 

•  A  Visual  Simulation  Composition  Environment  including 

-  The  ability  to  visually  create  models  and  run  simulations  composed  from 
components,  which  are  visually  represented  on  a  pallette 

-  Support  for  nested,  coupled  models 

-  Configuration  of  time  policies  for  individual  simulations  and  coupled  simulations 

-  Data  visualization 

•  A  simulation  engine  and  associated  repository  that  supports 

-  A  framework  support  for  nested,  coupled  simulations 

-  Time  Synchronization  for  coupled  dynamic  simulations 

•  Integration  of  atmospheric  models 

Preliminary  integration  of  HP  AC  through  its  CORBA  interface 

•  Resource  Management 

•  Integrated  Development  Environment  for  simulation  source  code 

•  Source  code  management  &  development 

•  Resource  versioning  &  management 

•  Uncertainty  representation  and  propagation 
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-  Libraries  of  performance  metrics 

-  Representations  of  uncertainty  for  different  classes  of  algorithms 

-  Propagation  of  uncertainty  across  coupled  simulations 

•  Software  Interfaces  for  components  to 

•  Source  code  /  executable  code 

•  Distributed  objects  (e.g.,  CORBA-compliant  objects) 

•  Composite  models 

•  Implementation  and  integration  of  models 

-  A  repository  of  primitive  composable  models  useful  for  constructing  more  complex 
simulations 

-  Artemis  CB  standoff  detector  models 

-  Surface  Acoustic  Wave  (SAW)  models  developed  by  the  University  of  Utah 

3.  Software  Architecture 
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4.  Selection  of  Core  Technologies 

At  the  beginning  of  the  Phase  II  effort,  the  investigators  identified  and  evaluated  several 
available  core  technologies  for  the  Phase  II  simulation  framework,  which  enabled  the 
development  of  the  software  implementation.  The  investigators  began  the  integration  of  core 
technologies,  such  as  the  Eclipse  open  source  Integrated  Development  Environment  (IDE) 
framework  and  Ptolemy  heterogeneous  concurrent  modeling  framework,  within  the  Phase  II 
software  framework.  Because  the  core  components  of  the  environment  are  written  in  the  Java 
programming  language,  it  can  operate  on  a  variety  of  hardware  and  software  environments.  All 
C  and  C++  development  is  compatible  with  the  GNU  gcc  compiler  suite  that  is  also  openly 
available  on  a  variety  of  platforms.  The  integration  of  these  technologies  provided  an  extensible 
and  configurable  simulation  development,  testing,  integration,  and  evaluation  environment. 
Furthermore,  these  technologies  provide  other  capabilities  (e.g.,  MatLab  integration,  software 
development  tools,  resource  management  tools)  that  directly  benefit  the  ultimate  product. 

4.1.  Eclipse 

The  Eclipse  project  is  an  open  source  framework  designed  to  provide  a  commercial-quality 
platform  for  highly  integrated  tools  (Eclipse  Foundation,  2005).  The  project  was  started  when 
IBM  released  approximately  $40  million  of  developed  software  as  open  source  technologies. 
Eclipse  is  a  cross-platform  framework,  already  supported  by  several  high-quality  tool  plug-ins: 

•  JDT,  an  open  source  Java  integrated  development  environment  (IDE); 

•  CDT,  an  open  source  C/C++  IDE; 

•  Open  source  resource  management  tools  (i.e.,  Team/CVS,  Stellation); 

•  Commercial  embedded  development  tools  (e.g.,  QNX); 

•  Data  modeling  tools  from  database  vendors  (e.g.,  Oracle,  Sybase);  and 

•  Rational™  modeling  and  software  life  cycle  tools. 

Although  Eclipse  is  a  relatively  new  technology,  there  is  a  lot  of  commercial  support  from  a 
number  of  companies  including  IBM,  RedHat,  QNX,  and  SyBase  allowing  a  large  amount  of 
responsiveness  to  the  needs  of  developers  using  the  framework. 

By  integrating  the  sensor  simulation  framework  within  Eclipse,  the  researchers  would  be  able  to 
provide  an  integrated  platform  for  simulation  development,  testing,  execution  and  analysis.  The 
Eclipse  framework  will  also  allow  the  researchers  to  provide  wizards  and  templates  to  increase 
the  usability  of  the  APIs.  The  Eclipse  framework  enables  different  utilities  and  tools  to  be 
configured  into  customized  services  according  to  user  roles  and  tasks. 

4.2.  Ptolemy 

Ptolemy  (University  of  California,  2003),  a  research  project  at  the  Department  of  Electrical 
Engineering  and  Computer  Science  at  the  University  of  California  Berkeley,  studies 
heterogeneous  modeling,  simulation  and  design  of  concurrent  systems.  Its  research  and 
associated  development  has  been  supported  over  the  last  ten  years  under  contracts  with  DARPA, 
NSF,  and  various  commercial  partners.  The  focus  of  their  research  is  on  embedded  systems, 
particularly  those  that  mix  technologies  including  analog  and  digital  electronics,  hardware  and 
software,  and  electronics  and  mechanical  devices.  They  also  focus  on  systems  that  mix  widely 
different  operations  such  as  signal  processing,  feedback  control,  sequential  decision  making  and 
user  interfaces. 
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The  Ptolemy  project  is  driven  by  the  principle  that  the  choices  of  models  of  computation  strongly 
impact  the  quality  of  a  system  design.  This  led  to  the  development  of  a  library  of  tools  capable 
of  combining  different  choices  of  computation  management  including  discrete  event,  discrete 
time,  continuous  time,  synchronous  data  flow,  and  finite  state  machines. 

In  addition  to  the  abstractions  in  computational  techniques  and  the  inherent  support  for  nested 
and  coupled  dynamic  simulations,  Ptolemy  also  offers  a  dynamic  typing  system  in  the  Java 
programming  language.  Ptolemy’s  dynamic  type  system  and  Java  implementation  were 
developed  by  Yuhong  Xiong  as  part  of  his  Ph.D.  thesis  from  U.C.  Berkeley.  The  type  system 
leverages  algorithms  from  the  ML  software  language  and  allows  run-time  type  checking  and 
lossless  hierarchical  type  conversion.  CogniTech  leveraged  and  extended  this  type  framework  to 
express  the  different  measures  of  uncertainty  required  for  this  effort. 


General 


of  California,  2003) 

5.  Development  of  Simulation  Framework 

The  investigators  developed  a  simulation  framework  that  combines  Ptolemy’s  simulation  engine 
and  visual  composition  environment,  extensions  to  handle  uncertainty,  Eclipse’s  source  code  / 
resource  management  capabilities,  and  additional  models  to  support  CB  detection  modeling.  All 
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programming  was  done  in  the  Java  programming  language.  The  Ptolemy  simulation  framework 
enables  the  composition  of  simulations  containing  different  or  hybrid  models  of  computation, 
including  discrete  event,  discrete  time,  continuous  time,  synchronous  data  flow,  and  finite  state 
machines. 

The  CogniTech  sensor  simulation  environment  enables  the  full  life  cycle  of  simulation  design, 
development,  integration,  test,  deployment,  analysis,  and  maintenance.  It  includes  an  Integrated 
Development  Environment  (IDE),  visual  composition  environment,  source  code  /  version 
management,  management  of  various  simulation  resources,  and  domain-specific  libraries,  to 
develop  chem/bio  detection  simulations. 


Table  1.  Current  Capabilities  of  CogniTech’s  Sensor  Simulation  Environment 


FEATURE 

ADVANTAGE 

BENEFIT 

Run-time  implementation 

Hierarchical  composition  of  simulations 

Simulation  environment  solves 
complex  problems  and  supports 
iterative  model  refinement 

Uncertainty 

representations 

Manages  representation,  propagation  & 
visualization  of  uncertainty 

Can  incorporate  &  analyze 
uncertainties  for  process  /  system 

Visual  composition 
environment 

Palette  of  components  for  visual  composition 
&  creation  of  new  components 

Create  new  components  &  rapidly 
use  components  to  create  complex, 
composite  simulations 

Role  /  User  configurable 
Workspace 

Allows  customized  user’s  workspace 

Increased  user  productivity 

Visualization  tools 

Provide  capability  to  graph  &  display  data 

Visually  display  simulation  results 

Source  code  management 
&  development 

Capabilities  to  manage  Java  &  C/C++ 
simulation  source  code 

More  time  &  cost-effective 
development  efforts 

Resource  versioning  & 
management 

Manage  other  forms  of  simulation  resources 

Multiple  users  can  search  for  & 
manage  versions  of  resources 

Distributed  Software 
Interface 

Prototype  for  CORB A  interoperability.  Plans 
for  HLA  and  BOM  interoperability  (not 
implemented  in  Phase  II). 

Interoperable  with  legacy  and 
future  software  that  uses  these 
distributed  communications 
standards 

Detailed  features  and  comparison  with  Mathworks  Simulink®  are  presented  below. 


Features/Benefits 

CogniTech 

Simulink® 

Visual  Composition  Environment 

✓ 

Matlab  Integration 

✓ 

Programming  Language  Interfaces 

Integrated  Debugger 

Uncertainty  Measures  and  Metrics 

Multiple  Concurrency  Models 

s+ 

Source  code  and  version  management 

s 

HI. A  (Planned)  and  CORBA  (Proof-of-Concept)  Integration 

HP  AC  Integration  (Proof-of-Concept) 

Open  API 

✓ 

Libraries  for  Chem/Bio  Simulation 

Table  2.  Comparison  of  Current  CogniTech  Environment  and  Mathworks  Simulink® 
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Within  the  sensor  simulation  environment,  simulations  can  initially  be  developed  or  integrated  at 
either  the  source  code  level  or  through  the  use  of  a  graphical  editor  to  visually  wire  simulation 
components  (primitive  simulation  units  or  more  complex  nested  components)  together.  The 
graphical  simulation  editor  stores  the  simulation  information  including  simulation  components 
and  their  connections,  scheduling  information,  and  user  specified  parameters  in  the  form  of  an 
XML  file  which  is  submitted  to  the  simulation  engine  for  execution.  Simulation  components  can 
be  simulation  source  code,  executable  libraries,  or  components  that  are  composed  from  these 
primitive  simulation  units.  Components  available  from  the  repository  appear  on  a  palette, 
available  to  support  the  user’s  visual  construction  of  more  complex  simulations  and  simulation 
components. 

5.1.  XML  Editor 

Leveraging  existing  open  source  tools,  CogniTech  developed  an  XML  editor  including 
simplified  syntax  highlighting  and  formatting  which  was  integrated  into  the  environment.  This 
editor  was  then  registered  for  file  type  association  within  the  workspace  allowing  automated 
execution  of  the  editor  when  opening  the  file  similar  to  the  file  association  familiar  from 
operating  systems.  Although  the  editor  is  not  “DTD  aware”  and  does  not  provide  automated 
markup  of  higher  order  data  structures  within  the  XML,  it  is  sufficient  for  present  use  and  will  be 
developed  further  based  on  project  needs  and  following  an  initial  end  to  end  implementation  of 
the  environment’s  required  functionality. 

5.2.  Simulation  Graph  Editor /  Visual  Composition  Environment 

CogniTech  is  leveraging  the  Vergil  graphical  simulation  editor  from  the  University  of  California, 
Berkeley  Ptolemy  project.  CogniTech  has  begun  the  integration  of  this  tool  into  the  Sensor 
Simulation  Workspace.  This  effort  aligned  both  graphical  and  Model  View  Control  abstractions 
between  the  workspace  and  Vergil.  Although  sections  of  the  original  Vergil  source  code  are 
modified,  CogniTech  localized  source  code  changes  and  minimized  their  footprint  to  enable  the 
seamless  integration  of  future  Vergil  releases  into  the  Sensor  Simulation  Environment. 

5.3.  Simulation  Resources,  Repository  and  Simulation  Execution 

After  the  graphical  construction  of  a  simulation  from  components,  the  simulation  can  be 
submitted  to  the  Simulation  Engine  for  execution.  The  Simulation  Engine  will  manage  the 
execution  of  the  defined  components  and  the  output/storage  of  the  data.  The  Simulation  Engine 
coordinates  the  execution  of  the  following  simulation  resources: 

•  components  bundled  with  the  initial  installation; 

•  components  dynamically  linked  from  within  the  user's  workspace,  and 

•  components  installed  as  libraries  following  initial  installation. 

5.4.  Uncertainty  Management 

A  major  focus  of  CogniTech’ s  Phase  II  research  was  the  ability  to  characterize  the  different 
types  of  uncertainties  within  a  simulation  and  simulation  components.  As  discussed  within 
previous  reports,  there  are  numerous  sources  and  types  of  uncertainty  within  sensor  and  CB 
sensor  simulations.  CogniTech  has  begun  the  implementation  of  abstract  data  types  for  using 
internal  uncertainty  representations  within  a  simulation.  Classical  statistical  measures  and  their 
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associated  operations  are  supported  within  the  environment.  In  addition,  the  simulation 
environment  provides  the  ability  to  be  extended  to  support  additional  measures  and  their 
operations.  Interval  measures  were  chosen  for  the  initial  implementation  because  they  are 
computationally  well  defined  and  provide  a  useful  basis  for  initial  uncertainty  representations. 

There  are  many  sources  of  uncertainty  that  can  impact  a  computational  modeling  result.  There 
are  uncertainties  in  model  parameters  and  experimental  data  used  by  a  computational  model. 
Since  computational  models  must  use  the  finite  set  of  floating-point  numbers  that  the  hardware 
makes  available,  there  are  uncertainties  associated  with  round-off,  truncation,  approximated 
mathematical  functions  and  other  operations.  Interval  mathematics  provides  a  relatively  simple 
way  to  quantify  such  uncertainties.  Interval  mathematics  is  a  generalization  of  real  mathematics 
that  uses  two  floating-point  numbers  to  bound  the  uncertainty  associated  with  each  real  number. 
Interval  arithmetic  (Alefeld,  1983)  can  protect  the  correctness  of  results  against  uncertain  data, 
rounding  errors,  and  inexact  algorithms. 

As  an  example  of  interval  computing,  suppose  we  wish  to  add  the  uncertain  parameter 
a  =  3.2  to  the  uncertain  parameter  p  =  7.3.  We  are  very  confident  that  a  is  known  to  within  0.3 
units,  and  P  is  known  to  within  0.2  units.  Using  this  information,  we  can  construct  the 
corresponding  intervals 

a  =  \a  -0.3,o  +0.3] 
and 

+0.2]. 

Therefore,  the  results  of  adding  these  values  are 

a  +  0  =  [2.93.5]+  [7.1, 7.5]=  [10.0,11.0]. 

According  to  the  operations  of  interval  arithmetic,  the  resulting  interval  is  calculated  by 

2.9  +  7.1  =  10.0 
and 

3.5  +  7.5  =  11.0. 

Therefore,  rather  than  a  simple  approximation  to  the  result  a  +  P,  we  have  a  reliable  conclusion 
that  the  true  solution  is  within  the  produced  bounds,  despite  uncertain  data,  finite  precision,  and 
approximation. 

The  process  of  propagating  intervals  throughout  the  entire  computation  guarantees  that  the  result 
of  the  interval  computation  is  contained  within  the  resulting  interval.  Given  the  simplicity, 
elegance,  and  utility  of  interval  mathematics,  this  was  the  initial  form  of  uncertainty  added  to  the 
simulation  framework. 

5.5  An  Overview  of  Current  Capabilities 

The  distribution  includes  a  sample  project  with  a  number  of  example  simulations  using  different 
synchronization  strategies.  The  examples  project  may  be  accessed  by  following  these  steps,  as 
shown  in  Figure  6: 

•  File>Import>Existing  Project  Into  Workspace  and 

•  browsing  to  and  selecting  the  Examples  directory  under  the  installed  workspace. 
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Figure  6.  Importing  the  Example  Project. 


Figure  7  shows  the  main  workspace  window  of  the  simulation  IDE.  The  leftmost  panel  is  a 
resource  explorer.  Different  resource  explorers  are  available  with  different  types  of  filtering 
based  on  resource  type  and  the  type  of  project.  In  this  case,  the  user  has  one  project  within  their 
workspace.  Each  project  has  a  specific  nature  associated  with  it  that  defines  the  default  editors 
and  information  viewers  when  accessing  the  project.  Within  the  “ChemBio  Simulations” 
project,  the  user  has  several  .moml  simulation  files  that  describe  the  composition  of  the 
simulation  components  and  synchronization  strategy. 
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Figure  7.  Simulation  Workspace  with  Source  Code  View 


In  the  top  center  panel  of  Figure  7,  the  workspace  contains  a  Java  Editor  for  the  source  code  of  a 
simulation  unit.  In  this  case  it  is  the  source  code  of  a  model  simulating  the  behavior  of  a  Surface 
Acoustic  Wave  sensor. 


Below  the  Java  editor,  notice  the  Task  Window.  By  default,  this  will  list  compiler  warnings  and 
errors.  When  a  user  double  clicks  on  an  entry  in  the  Task  Window,  the  appropriate  editor  opens 
and  brings  focus  to  the  appropriate  location  in  the  file.  The  user  can  also  configure  the 
workspace  to  use  custom  keywords  such  as  “TODO”  as  a  task  flag.  Users  of  the  simulation 
workspace  can  drag-and-drop  or  resize  different  views  (e.g.,  source  code,  hierarchy,  resources) 
of  simulation  components  into  a  persistent  customized  workspace  configuration. 
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Figure  8.  Simulation  Environment  with  open  Simulation  Graph  Editor 

When  an  MOML  XML  file  is  opened  within  the  workspace,  a  Simulation  Graph  Editor  (as 
shown  in  Figure  8  above)  is  automatically  launched.  On  the  left  side  of  the  Simulation  Graph 
Editor,  the  Repository  Palette  contains  reusable  simulation  components  that  may  be  dragged  and 
dropped  to  perform  simulation  wiring  and  other  simulation  construction  tasks.  Below  the 
Repository  Palette,  a  navigation  window  allows  the  user  to  easily  move  the  focus  of  the  main 
Graph  Editor  pane.  Within  the  main  Graph  Editor  pane,  the  simulation  is  visually  constructed. 
Each  simulation  contains  a  Director  which  manages  the  synchronization  between  components. 
Different  Director’s  are  available  for  different  synchronization  schemes  (discrete  event, 
continuous  time,  etc.). 

The  model  in  Figure  8  shows  an  example  of  a  graphically  composed  LIDAR  model  that 
determines  the  detection  probability  of  an  agent  based  on  various  parameters  including  species 
absorption  wavelength  and  range.  Components  within  the  editor  Using  the  El  icon  are  nested 
simulations  each  with  their  own  Director  and  synchronization  strategy.  Figure  9  shows  the 
internal  construction  of  one  of  these  sub-models. 
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Figure  9.  Visually  composed  nested  LIDAR  model  component 


Individual  models  are  opened  by  double  clicking  on  the  “moml”  file.  The  Run  Window  is 
accessed  from  the  Graphical  Simulation  Editor  by  following  these  steps: 

•  View>Run  Window  and 

•  Clicking  the  “Go”  button  begins  execution. 

The  data  resulting  from  running  a  simulation  can  be  presented  to  the  using  through  visualization 
capabilities. 

5.6  Visualization 

The  simulation  environment  provides  the  ability  to  plot  and  chart  simulation  data  and  view  the 
evolution  of  these  plots  in  real  time  as  the  simulation  evolves.  In  addition,  the  simulation 
environment  provides  an  API  for  the  development  of  custom  visualizations  including  animations 
that  leverages  Sun  Microsystems  Java  Imaging  library. 

In  addition  to  basic  visualization  capabilities,  specific  visualization  tools  were  developed  to 
support  the  Phase  II  research.  After  interval  measures  for  uncertainty  were  added  as  a  basic  data 
type  for  the  simulation  framework,  the  investigators  decide  to  add  custom  visualization  tools  to 
represent  this  form  of  uncertainty.  The  existing  visualization  utilities  were  augmented  to  display 
the  span  of  an  interval  measure  within  a  graph.  Figure  10  in  section  6.3  illustrates  an  example  of 
visualization  for  data  from  a  LIDAR  simulation. 

6.  Model  Development  and  Analysis 

One  of  the  most  significant  contributions  of  this  research  was  recasting  mathematical 
representations/models  of  the  operating  mechanisms  for  point  and  standoff  detectors.  This  was 
demonstrated  using  two  models  of  chemical  detectors:  a  baseline  model  of  a  LIDAR  standoff 
detection  system  and  an  in-depth  model  of  a  SAW  chemical  point  detector. 
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6.1.  LIDAR  Models 


6.1.1.  Overview  of  LIDAR  Systems 

Active  standoff  detection  using  differential  absorption  lidar  (DIAL)  is  an  ongoing  area  of 
research  for  atmospheric  chemical  detection  and  systems  using  a  wide  number  of  different 
measurement  and  analysis  techniques  have  been  developed.  DIAL  systems  provide  the  ability 
for  three-dimensional  mapping,  identification  and  quantification  of  chemical  species’ 
concentration  profiles  within  the  atmosphere.  To  accomplish  this,  laser  light  is  transmitted  into 
the  atmosphere  at  two  similar  wavelengths.  One  wavelength  is  chosen  at  which  the  species 
under  investigation  absorbs  the  light  and  the  second  is  a  near  (off  peak)  wavelength.  If  the  two 
pulses  are  made  close  enough  in  time  such  that  the  atmosphere  can  be  considered  stationary,  the 
off  peak  laser  pulse  is  assumed  to  have  similar  atmospheric  transmission  characteristics  to  the  on 
peak  wavelength  except  for  optical  absorption  by  the  chemical  species.  Comparison  of  the 
intensities  of  the  backscattered  pulses  given  the  concentration  of  the  investigated  species  in  the 
region  of  atmosphere  examined.  Range  is  determined  by  resolving  the  arrival  time  of  the 
returning  pulses. 

6.1.2.  DoD  LIDAR  Model 

To  demonstrate  the  present  capabilities  of  the  sensor  simulation  environment,  CogniTech  used 
simplified  LIDAR  model  obtained  from  the  Artemis  program  was  implemented  within  the  sensor 
simulation  environment.  Within  the  sensor  simulation  environment,  users,  at  present,  may  chose 
one  of  two  methods  for  implementing  simulations.  First,  the  sensor  simulation  environment 
provides  a  repository  of  useful  simulation  components  (Atomic  Actors)  that  may  be  wired 
visually  to  construct  a  composite  simulation.  In  addition,  users  may  otherwise  opt  to  develop 
component  simulations  leveraging  the  existing  software  API  and  libraries. 

For  demonstration  purposes,  the  Artemis  LIDAR  model  was  implemented  using  primitive 
simulation  units  available  within  this  distribution.  Since  model  components  only  rely  on 
incoming  data  on  which  to  operate,  the  Synchronous  Dataflow  director  was  chosen  for  both 
implementations. 

The  Artemis  LIDAR  model  has  sixteen  adjustable  parameters.  From  these  parameters,  the 
model  predicts  the  probability  of  direct  detection 

•  noise  power  and  plots  the  following  versus  range; 

•  carrier  to  nose  ratio; 

•  signal  to  noise  ratio; 

•  instantaneous  signal  to  noise  ratio;  and 

•  probability  of  detection. 

The  LIDAR  model  was  implemented  with  nested  models  for  the  noise  power,  carrier  to  noise 
ratio,  signal  to  noise  ratio,  and  probability  of  detection. 

6.1.3.  Analysis  of  LIDAR  Simulation  and  Uncertainty 

Figure  10  shows  the  results  of  the  probability  of  detection  LIDAR  simulation  for  both  expected 
and  numerically  uncertain  outputs.  The  bottom  portion  of  this  figure  shows  the  result  from 
introducing  small  uncertainties  in  the  detection  threshold  and  false  alarm  rate  parameters.  The 
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interval,  representing  uncertainty  in  the  detection  probability  curve,  is  represented  by  error  bars 
on  a  discrete  sampling  of  points.  For  clarity,  the  entire  probability  of  detection  curve  is  not 
plotted.  Through  the  use  of  interval  mathematics,  these  uncertainties  were  propagated  throughout 
the  model  calculations  to  produce  the  intervals  shown  in  the  lower  half  of  this  figure.  The  utility 
of  interval  mathematics  is  its  ability  to  provide  insight  into  how  uncertainty  of  selected 
parameters  may  impact  uncertainty  associated  with  a  system.  The  top  part  of  the  figure  suggests 
that  the  probability  of  detection  is  near  one  up  to  about  nine  km.  Between  nine  and  eleven  km, 
the  probability  transitions  to  zero.  The  lower  plot  shows  sensitivity  to  uncertainty  in  the  region 
between  nine  and  eleven  km,  indicated  by  larger  error  bars. 

Detect!  ©  n  Frobabii  I  ty 


Detection  Probability  interval 


Figure  10.  Calculated  Detection  Probabilities  (Soller,  2003) 

6.2.  Surface  Acoustic  Wave  (SAW)  Chemical  Sensor  Models 

6.2.1.  A  Summary  Description  of  the  SAW  Detection  Process 

A  SAW  sensor  exposed  to  a  target  gas  responds  by  adsorbing  a  fraction  of  the  input  gas 
concentration.  The  gas  adsorbed  increases  the  mass  of  a  chemically  sensitive  coating  layer  on  a 
piezoelectric  substrate.  This  increased  mass  will  lower  the  resonance  frequency  of  the 
piezoelectric  resonator  controlled  oscillator  circuit  that  comprises  the  chemical  detector.  In 
addition,  the  adsorbed  gas  can  change  the  mechanical  properties  of  the  chemically  sensitive 
(usually  polymer)  coating  layer  on  the  substrate.  This  also  changes  the  resonant  frequency  of  the 
circuit. 

The  output  of  the  SAW  detector  is  the  change  in  frequency  of  the  oscillator/resonator.  The 
change  in  frequency  depends  on  the  type  of  gas,  the  concentration  of  input  gas  in  the  chemically- 
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sensitive  layer,  and  any  resultant  change  in  mechanical  properties  of  the  chemically  sensitive 
layer.  The  resulting  steady  state  frequency  change  is  the  primary  means  used  to  separate  input 
gas  mixtures  into  constituent  components. 

SAW  sensors  are  observed  to  reach  steady  state  over  a  range  of  times.  Similarly,  when  the  target 
gas  is  removed,  the  sensors  return  to  their  original  states  (original  resonant  frequencies)  over  a 
range  of  times.  The  attainment  of  steady  state  is  governed  by  a  combination  of  adsorption  of  gas 
on  the  surface  of  the  chemically  sensitive  layer  and  the  diffusion  of  gas  through  this  layer.  Both 
of  these  properties  depend  on  the  type  of  polymer  used  and  the  target  gas. 

The  clear  down  or  fall  time  of  a  chemical  sensor  depends  upon  the  diffusion  of  gases  out  of  the 
sensitive  layer  and  the  subsequent  desorption  of  gases  from  the  surface.  Desorption  is  a 
thermally-activated  process,  whose  activation  energy  depends  upon  the  interaction  energy 
between  the  molecules  of  the  sensitive  layer  and  the  molecules  of  the  target  input  gas.  These 
vary  for  different  layers  and  gases. 

The  physico/chemical  parameters  that  describe  the  SAW  sensor  response  are  mostly 
temperature-dependent.  The  temperature  dependence  is  often  complex,  and  varies  depending  on 
sensitive-layer  molecules  and  target  gas  molecules. 

All  electronic  devices  and  transducers  exhibit  fluctuations  in  their  output.  These  fluctuations 
exhibit  root  mean  squared  (RMS)  values  and  a  spectrum  of  power  versus  frequency.  The  noise 
spectra  can  be  time  varying  if  the  mechanisms  underlying  the  noise  spectra  vary  with  time.  These 
fluctuations  of  resonant  frequency  vary  with  film  geometry,  rate  of  gas  adsorption  into  the  film, 
and  fluctuations  in  transport  properties  of  gas  molecules  in  the  film.  The  fluctuations  in  transport 
properties  are  dependent  on  the  structure  and  composition  of  the  film. 

A  detailed  analysis  of  the  dynamic  response  of  a  SAW  sensor  or  an  array  of  SAW  sensors  yields 
information  about  these  operating  mechanisms.  Different  time  windows  of  the  device  output  can 
be  analyzed  to  understand  the  impact  of  these  mechanisms  on  device  performance. 

6.2.2.  Modeling  of  SAW  Detection  Process 

The  investigators  developed  a  model  for  SAW  chemical  sensors  that  incorporated  models  of  the 
various  operating  mechanisms.  The  overall  SAW  sensor  model  was  implemented  as  a  collection 
of  coupled  software  components.  Each  software  component  represents  a  model  of  a  single 
operating  mechanism  or  collection  of  mechanisms,  whose  inputs  and  other  parameters  are 
adjustable.  By  contrast,  conventional  SAW  models  are  either 

•  oversimplified  or 

•  make  it  difficult  to  implement  localized  variations  in  their  complex  boundary  conditions, 
which  include  multidimensional  relationships. 

Conventional  SAW  models  do  not  readily  permit  accurate  tradeoff  analyses  for  upgrading  or 
adapting  detectors  to  improve  the  performance  of  existing  detector  systems  or  for  responding  to 
new  threats. 
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Over  a  more  limited  domain,  the  models  developed  in  the  Phase  II  research  provide  the 

•  the  accuracy  approaching  the  more  complex  models  and 

•  flexibility  to  support  a  number  of  detector-related  design  and  analysis  tasks. 

Therefore,  the  component-based  modeling  approach  developed  by  CogniTech  and  the  University 
of  Utah  is  more  suitable  for  the  analysis  and  design  of  SAW  and  other  detector  arrays. 

The  dynamic  models  were  first  implemented  in  the  C++  programming  language  by  the 
University  of  Utah.  The  following  operating  mechanisms  were  implemented: 

1 .  Adsorption  from  gas  phase  to  the  surface,  where  Langmuir  and  Fruendlich  isotherms 
were  treated  individually 

2.  Diffusion  from  the  surface  into  the  chemically-sensitive  film,  where  linear  (Fickian) 
diffusion,  concentration  dependent  diffusion,  and  non-linear  diffusion  mechanisms  were 
treated  individually 

3.  Desorption  from  the  chemically  sensitive  film,  where  transport  (diffusion)  limited 
desorption  and  thermal  (interaction  energy  limited)  desorption  were  treated  individually 

4.  Steady  state  sensor  output,  using  mass  loading  (ideal)  and  mass  loading  plus  changes  in 
viscoelastic  properties  (non-ideal) 

5.  Noise  spectral  density,  sometimes  called  noise  floor,  based  on  the  sum  of  noise  in  a  SAW 
device  plus  Poisson  noise  due  to  adsorption/desorption  and  transport  noise  due  to 
diffusion. 

6.  Dynamic,  time-dependent  sensor  output  using 

-  diffusion  and  adsorption  mechanisms  as  enumerated  in  (1)  and  (2)  for  the  rise  time 
and 

-  diffusion  and  desorption  mechanisms  as  enumerated  in  (2)  and  (3)  for  the  clear  down 
(fall)  time. 

Parameters  and  specialized  models  were  identified  for  various  combinations  of  SAW  device 
configurations  (e.g.,  gases,  substrates,  chemically-sensitive  layers,  processing)  and  atmospheric 
(e.g.,  temperatures,  pressure,  humidity).  The  outputs  of  these  models  were  plotted  for  different 
polymer  substrates  and  different  target  gases  and  shown  in  figures  11-15.  The  development  of 
the  component-based  models,  their  scientific  basis,  and  their  C++  implementation  are  presented 
in  two  recent  master’s  theses  at  the  University  of  Utah  (Cha,  2005;  Pandita,  2005). 

These  models  could  have  been  integrated  directly  from  the  C++  code  or  converted  to  Java 
components.  CogniTech  made  the  decision  to  re-implement  the  models  in  the  Java  programming 
language  to  simplify  long-term  maintenance  of  the  models.  The  Java  implementation  of  the 
SAW  models  was  integrated  into  the  visual  drag  and  drop  software  environment  described  in 
section  5.  In  this  environment,  a  non  specialist  in  chemical  detectors  can  easily  adjust 
complexity,  materials,  algorithms,  and  interconnections  in  a  detector  array  model  to  simulate  the 
behavior  of  array  and  enable  analysis.  This  represents  a  significant  advance  in  the  analysis, 
selection,  upgrading  and  adaptation  of  chemical  detectors. 

6.2.3.  Data  Obtained  from  Component  Base  Simulations  of  SAW  Sensors 

The  graphs  shown  below  illustrate  typical  outputs  from  the  simulation  of  SAW  sensors  using  the 
models  described  in  section  6.2.2.  Figure  1 1  shows  how  steady  state  is  approached  after  the 
sensor  is  exposed  to  the  target  gas.  The  concentration  builds  up  over  time  until  equilibrium  is 
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attained.  At  equilibrium,  adsorption  from  the  gas  phase  is  balanced  by  desorption  to  the  gas 
phase.  Figure  12  shows  how  the  level  of  fluctuations  is  minimized  in  steady  state  and  that  a 
major  contributor  to  the  fluctuations  is  the  shot  noise  associated  with  adsorption  and  desorption 
processes.  Figure  13  is  the  counterpart  of  figure  11  in  the  response  domain  and  shows  the  change 
in  frequency  during  the  adsorption  of  the  target  gas.  The  frequency  change  with  time  approaches 
zero  as  steady  state  is  attained.  Figure  14  shows  the  dynamic  output  of  the  detector  for  two 
different  gases.  It  is  noteworthy  that  the  rise  time  differs  between  the  two  gases  even  though  the 
steady  state  values  are  comparable.  Figure  15  shows  the  Poisson  noise  for  this  detector.  As 
expected,  it  reaches  a  minimum  at  steady  state.  The  zero  value  refers  to  the  noise  in  the  oscillator 
that  would  appear  in  a  saw  that  wasn’t  used  as  a  chemical  detector. 


mass  vs  time 


time 

Figure  11.  Dynamic  Mass  Addition  and  Change  in  Polymer  of  Sensor 
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Noise  vs  Time 
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Figure  12.  Noise  in  Sensor  Response  due  to  Sorption  of  Molecules 


Frequency  vs  time 
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Figure  13.  Output  Frequency  versus  Time,  Normalized  to  Resonant  Frequency 
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Figure  15.  Frequency  vs.  Concentration  Change  at  Steady  State 
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This  research  developed  the  most  comprehensive  SAW  chemical  sensor  model  reported  (to  our 
knowledge)  in  the  literature.  Specifically,  this  model  provided 

•  The  first  scientifically  (as  opposed  to  network  based)  model  of  a  SAW  sensor  that 
includes  rise  time,  cleardown  time  and  noise  level 

•  The  discovery  that  a  detailed  analysis  of  a  SAW  sensor  output  provides  much  more 
understanding  than  the  static  response,  or  even  the  temperature  dependent  static  response. 

•  Decomposition  of  SAW  output  into  component  contributions  permits  optimizing  a  device 
by  determining  the  impact  of  proposed  changes  upon  particular  parts  of  the  device 
performance. 

6.3.  DTRAHPAC 

6.3.1  Overview 

The  Defense  Threat  Reduction  Agency’s  Hazard  Prediction  and  Assessment  Capability  (HP AC) 
computer  model  (Lee,  2002)  uses  the  atmospheric  dispersion  model  SCIPUFF  (Second-order 
Closure  Integrated  Puff)  as  its  backend  dispersion  simulation.  SCIPUFF  was  the  first  widely 
accepted  vapor  dispersion  model  with  an  explicit  parameterization  of  model  uncertainty. 

SCIPUFF  uses  a  Lagrangian  puff  dispersion  model  developed  by  Titan's  ARAP  Group  that  uses 
a  collection  of  Gaussian  puffs  to  represent  an  arbitrary,  three-dimensional  time-dependent 
concentration.  The  turbulent  diffusion  parameterization  is  based  on  turbulence  closure  theory, 
providing  a  direct  relationship  between  the  predicted  dispersion  rate  and  turbulent  velocity 
statistics  of  the  wind  field.  In  addition  to  the  average  concentration  value,  the  closure  model  also 
provides  a  prediction  of  the  statistical  variance  in  the  concentration  field  resulting  from  the 
random  fluctuations  in  the  wind  field.  The  closure  approach  also  provides  a  direct  representation 
for  the  effect  of  averaging  time. 

The  principle  advantage  of  the  Lagrangian  approach,  for  dispersion  modeling,  is  the  absence  of 
any  numerical  grid,  so  that  the  enormous  range  of  scales  involved  in  dispersion  from  a  localized 
source  onto  the  mesoscale  or  larger  can  be  accurately  represented  . 

HP  AC  includes  the  ability  to  interface  with  several  meteorological  data  servers  in  addition  to  the 
ability  to  accept  data  from  larger  scale  meteorology  simulations  such  as  MM5.  HPAC  also 
models  dense  gas  behavior  and  includes  the  ability  to  specify  linear  decay  rates  for  any  species. 

6.3.2  Software  Interface 

HPAC  was  chosen  as  the  demonstration  vapor  dispersion  model  because  it  already  has  external 
CORBA  interfaces  available.  With  the  assistance  of  DTRA  staff,  SAIC  and  Oak  Ridge  National 
Laboratory,  CogniTech  developed  a  simulation  module  for  use  within  the  sensor  simulation 
environment  using  the  HPAC  dispersion  engine.  This  module  invokes  the  HPAC  software 
running  on  the  same  or  a  remote  system  to  operate  on  previously  configured  scenarios  and  return 
the  simulation  data.  The  module  was  written  in  the  Java  programming  language  and  tested  with 
both  stand-alone  and  distributed  configurations.  The  HPAC  software  itself  must  be  run  on  a 
Microsoft  Windows  platform,  but  may  be  invoked  from  the  CogniTech  client  running  on  any 
platform  that  supports  Java  (e.g.  Windows,  Linux,  Unix). 
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7.  Conclusion 

The  research  performed  in  this  Phase  II SBIR  contract  developed  a  generalized  architecture, 
framework,  and  methodology  for  the  modeling  and  simulation  of  chemical  and  biological  (CB) 
detectors.  The  software  environment  integrates  atmospheric  models,  detector  models, 
uncertainty  measures,  and  a  variety  of  time-synchronization  and  model  composition  capabilities. 
This  framework  provides  distributed  access  to  models  and  simulations.  Simulation  components 
were  developed  for  standoff  and  point  detectors,  including  the  most  complete  dynamic  model  of 
the  Surface  Acoustic  Wave  (SAW)  chemical  sensor  to  date. 

The  data  resulting  from  the  simulations  enabled  analysis  of  various  detector  capabilities  and 
tradeoffs  using  multiple  metrics.  Future  directions  include  the  development  and  integration  of  an 
enhanced  environment;  more  comprehensive  suite  of  sensor  models;  a  database  for  experimental 
and  simulated  data;  sensor  data  interpretation  algorithms;  and  data  fusion  to  support  seamless 
modeling,  design,  testing,  and  analysis  for  current  and  future  chemical  and  biological  detection 
assets.  In  addition,  this  technology  can  serve  as  the  foundation  for  a  sensor  simulation  capability 
to  be  integrated  with  DoD  atmospheric  hazard  dispersion  models  and  an  interface  to  decision 
support  systems. 
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